Scope the checkins collection group, and serve pet history from a callable - #190

collectionGroup('checkins').where('userId','==',victim).orderBy('createdAt') returned a person's movement timeline — every place they have physically been, with timestamps — to an unauthenticated caller with no rate limit. Both the (userId, createdAt) and (petId, createdAt) collection-group indexes exist, so this was servable today.

⚠️ The brief was wrong about one thing, and following it would have broken a live feature

Delete the getCheckinsByUser dead code — it has no callers.

The function is getUserCheckins, and it is not dead: Profile.tsx:130 calls getUserCheckins(user.uid) to render the signed-in user's own check-ins tab.

Deleting it, or closing the rule outright with allow read: if false as the brief implied, would have removed a user's ability to see their own check-in history.

So the rule is scoped to the requesting user rather than closed:

allow read: if isAuthenticated() && resource.data.userId == request.auth.uid;

This still closes both harvesting paths. The brief's core point was right — tightening only userId is theatre, since pets/{petId} is world-readable and carries ownerId — but scoping achieves it anyway: a petId-filtered collection-group query can return documents belonging to other people, so Firestore refuses it outright. There's a test pinning exactly that, including that even the pet's own owner is refused.

The pet profile

Moves to getPetCheckinsCallable. Still public, no login — check-ins are content the user chose to publish and that page has always shown them. The exposure was never visibility, it was bulk harvesting with no ceiling. So:

• rows capped at 100 regardless of what's asked for
• assertRateLimit, bucketed by uid when signed in and by client IP when not, so an anonymous scraper can't get an unlimited budget by staying logged out
• no userId / userName / userAvatar in the response. The page never rendered them, and leaving them out means this route can't be reassembled into a per-person lookup either

locations/{id}/checkins is untouched and still world-readable — that's a per-place question, not a per-person one.

Tests

Rules, 6 new — 4 fail on the old rule:

× refuses a query for someone else's history
× refuses an unauthenticated query for anyone's history
× refuses the petId route, which is the same leak one hop away
× refuses an unfiltered collection-group scan

Two pass on both, as guardrails: an unauthenticated read of one location's check-ins, and a user querying their own history — the Profile tab the brief would have broken.

Callable, 8 new: the public path, newest-first ordering, the row cap under an absurd limitCount, the absent identity fields (asserted both by key and by scanning the serialised response for the uid), cross-pet isolation, requiredDocId validation, and the empty case.

Local: rules 74/74, functions test:emulator 88/88, typecheck:test / typecheck:tests / both builds clean.

Deploy

Rules first, then functions — the client change depends on the callable existing.

firebase deploy --only firestore:rules
firebase deploy --only functions

Noted separately, not bundled: the deletion cascade does not clean up locations a user added.

🤖 Generated with Claude Code